漏洞10年深藏不露，PHP 项目依赖关系管理工具Composer安全吗？
数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。
随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。
为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。
注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。
2021年4月21日，Composer 中被发现命令注入漏洞，震惊了整个 PHP 社区。好在它并没有带来多大的影响，但它具备这个能力。该漏洞的问题在于，它影响的是 Composer 供应链的最核心部分：Packagist 服务器。
要不是及时发现了这个漏洞，后果将不堪设想，因为 PHP 支持着80%的 web 且它们多数使用的就是 Composer。
如 Packagist 服务器受陷，则可导致维护人员的凭据遭泄露或者下载内容被重定向到恶意服务器，导致难以预测的行为如蠕虫传播、后门等。好在，Composer 和 Packagist 的维护人员立即响应，在12小时内修复该问题。目前并未发现该漏洞遭利用的迹象。
但美中不足的一点是，虽然多数基于 php 的项目使用的是公开库 (packagist.org)，但也存在被私下托管的可能性。如果私营组织机构出现了这个情况，则Packagist 的维护人员显然无法应用修复方案。
要了解如何在 Packagist 服务器上执行恶意代码，必须懂一点 Composer 的内部运行原理。
Composer 是一个 Php 脚本，必须出现在托管着Php 项目的且依赖它管理依赖关系的所有服务器中。部署应用程序新版本后，必须提取依赖关系。在实践中，这就意味着调用一个 Composer 命令——composer install 的某种变体。当要求安装新的软件包时，Composer 就会联系仓库（很可能是 https://packagist.org）查找集成到项目中的库的元数据。
该元数据的一个重要内容是库代码的 URL，它将被下载并本地存储在 vendor/sub-directory中。该RUL 一般指向一个 CVS，如：
{
“name”: “abdielcs/expanded-collection-bundle”,
“version”: “v0.1.2”,
“source”: {
“type”: “git”,
“url”: “https://github.com/abdielcs/ExpandedCollectionBundle.git”,
“reference”: “3e535cee26825982f9b60d1ffb72a0ddccb6b542”
}
}上述 json 结构是 Packagist 按照包含 abdielcs/expanded-collection-bundle 的库请求返回的。其中，它告知本地 Composer 安装程序从属性 url 指向的 URL 中找到的仓库中查看，本案例中为：
https://github.com/abdielcs/ExpandedCollectionBundle.git.由此可见，Packagist 仅仅是元数据仓库，实际托管库代码是每个个体维护人员的责任。因此，Packagist 作为庞大的目录，以某种方式将包名称翻译为下载URL。
由于 Packagist 是一个公开目录，因此任何人都能轻松上传新包，实际上只要有邮件地址就能上传。而这正是它快速增长并流行起来的原因。但同时它也带来了漏洞。Packagist 不会执行很多验证，而只是验证json结构是正确的，这就可疑在“来源”定义中放置除了 URL 的东西。当然 Composer 脚本确实对 URL 进行了一些清理，但最终该信息直接进入外部VCS命令，从而带来了利用机会。
恶意命令注入通过未验证选项完成，如：
return ‘git ls-remote –heads ‘ . ProcessExecutor::escape($url);在本例中，git 被调用为操作系统命令，而外部输入 ($url) 得到正确清理。
但，如果url 以 “-“ 开头呢？
在本例中，实际被调用的真正命令并非开发人员预想的，而这就是问题浮现的地方。当 Packagist 发现新软件包时会立即查询仓库URL，以获得一些基础信息并让所有人知晓。这意味着如果 URL 中包含恶意代码，则将在 Packagist 上执行，而研究员 Thomas Chauchefoin 就是这么做的。
使用构造精良的源URL，再结合 Mercurial 不太知名的特性，Thomas 及其团队可在 Packagist 服务器上执行任意命令，有效地证实了它的可行性。
而有意思的是，该漏洞在十多年前就已经出现了！
漏洞存在如此长的时间说明了“参数注入”类威胁的隐秘性。不过防御此类威胁的最佳方式仍然是避免执行从包含用户提供输入的字符串创建的外部命令。
然而，在本例中尚不清楚，既然Composer 的其中一个目标是 VCS （版本控制系统）独立，为何会产生这类漏洞。因此，考虑到多个 VCS 版本的存在，可能并非每个版本都是原生的PHP实现。
随着软件开发流程变得愈加复杂，覆盖开源供应链中的每个阶段极其困难。如果项目规模庞大，它们多数一定会依赖于可被攻陷的第三方组件。本文提到的 Composer 漏洞就说明了用于管理此类依赖关系的工具也可能易受攻击。
确保自己安全的最佳方法就是依靠自动化工具监控并尽快提供安全漏洞警报，而奇安信开源卫士就是这样一款工具。
@whyseu @。@HFwuhome@惊蛰 @nimo @XuZ @淡然 @Marco韬 @王孟 @Wecat@nwnλ @MOBE @湘北二两西香葱@※ @搬砖小土妞@云烟过眼 @r00t@小风 @傲雪@最好走的路是套路 @Zhao.xiaojun @浅笑淡然 @X-Star @Erick2013 @小秦同学 @X @王骏 @欢寻 @nbp@Mr. Guo
大家可移步京东电子工业出版社一睹为快！或直接点击“原文链接”购买。如下是本书相关讲解:
奇安信代码安全实验室主任黄永刚在2021年北京网络安全大会上也发布了实验室在软件供应链安全方面相关的研究成果。
在线阅读版：《2021中国软件供应链安全分析报告》全文因使用五年前的老旧代码，Azure 容器险遭黑客接管，微软已修复
微软“照片”应用Raw 格式图像编码器漏洞 (CVE-2021-24091)的技术分析
速修复！热门npm 库 netmask 被曝严重的软件供应链漏洞，已存在9年
SolarWinds 供应链事件后，美国考虑实施软件安全评级和标准机制
找到软件供应链的薄弱链条
GitHub谈软件供应链安全及其重要性
揭秘新的供应链攻击：一研究员靠它成功入侵微软、苹果等 35 家科技公司
谷歌Linux基金会等联合推出开源软件签名服务 sigstore，提振软件供应链安全
Linus Torvalds 警告：勿用 Linux 5.12 rc1，担心供应链攻击？
微软和火眼又分别发现SolarWinds 供应链攻击的新后门
找到恶意软件包：Go 语言生态系统中的供应链攻击是怎样的？
拜登签署行政令，要求保护美国关键供应链（含信息技术）的安全
坐火车太无聊，我溜入微软 VS Code官方GitHub仓库，但没敢发动供应链攻击
SolarWinds 供应链攻击中的第四款恶意软件及其它动态
OpenWRT开源项目论坛遭未授权访问，可被用于供应链攻击
FireEye事件新动态：APT 攻击 SolarWinds 全球供应链（详解）
FireEye 红队失窃工具大揭秘之：分析复现SolarWinds RCE 0day (CVE-2020-10148)
FireEye红队失窃工具大揭秘之：分析复现Zoho ManageEngine RCE (CVE-2020-10189)
FireEye 红队失窃工具大揭秘之：分析复现 Zoho 任意文件上传漏洞(CVE-2020-8394)
FireEye 红队失窃工具大揭秘之：分析复现 Confluence路径穿越漏洞 (CVE-2019-3398)
FireEye 红队失窃工具大揭秘之：分析复现 Atlassian RCE (CVE-2019-11580)
Ripple 20：严重漏洞影响全球数十亿IoT设备，复杂软件供应链使修复难上加难
被后爹坑：开源 JavaScript 库沦为摇钱树
速修复！开源企业自动化软件 Apache OFBiz 出现严重的 RCE 漏洞
谷歌提出治理开源软件漏洞的新框架：知悉、预防、修复
开源软件漏洞安全风险分析
开源OS FreeBSD 中 ftpd chroot 本地提权漏洞 (CVE-2020-7468) 的技术分析
集结30+漏洞 exploit，Gitpaste-12 蠕虫影响 Linux 和开源组件等
原文链接：
https://www.whitesourcesoftware.com/resources/blog/supply-chain-attack-against-composer/
题图：Pixabay License
奇安信代码卫士原创出品。转载请注明 “转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的
产品线。